Verifying subscriber information for device-based authentication

ABSTRACT

A subscriber information authentication system that compares network-obtained and device-obtained information to verify that a device being used in connection with a user account is authenticated for that account. Certain subscriber information may be associated with the account during a registration process. In subsequent attempts to access the account, the registered subscriber information may be used in conjunction with information obtained from a telecommunication network and from a device to verify that the device is authorized. The information from the telecommunication network may be queried using Signaling System No. 7 (“SS7”) protocols. The device authorization may be performed, for example, to ensure that a device being used for device-based verification is the device a user purports it to be.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. patent application Ser. No.16/518,744, filed on Jul. 22, 2019, entitled “VERIFYING SUBSCRIBERINFORMATION FOR DEVICE-BASED AUTHENTICATION,” the disclosure of which isincorporated herein by reference in its entirety for all purposes.

Individuals increasingly maintain user accounts with Internet websites,cloud-based applications, and other online services. In light of thesensitivity of information that is typically associated with these useraccounts (e.g., financial records, health records, professional andsocial network connections, etc.), it is crucial that attempts to accessthese accounts be properly authenticated (i.e., verifying that oneattempting to access an account is who they purport to be).

Online services typically use traditional username and password checksas a first layer of security. To improve account security, onlineservices are increasingly providing or requiring additional layers ofsecurity that involve a verification device associated with a useraccount. For example, a common second layer of security involves theexchange of a one-time code between the online service and the user viathe verification device, such as a smartphone. Typically, the codeexchange will involve a communication channel different from that usedto request access to the online service. For example, a user may attemptto access an online service from a login device that communicates withthe online service through the Internet, while portions of the codeexchange may be carried out between the online service and verificationdevice through a telecommunication network. To maintain the fidelity ofthese additional layers of verification device based security, known andtrusted identifiers for communicating with verification devices areoften maintained by online services in connection with correspondinguser accounts. Verified subscriber information, such as a telephonenumber, may, for example, be associated with a user account during anaccount registration process.

Unfortunately, various techniques exist for spoofing subscriberidentifiers, thereby enabling “man-in-the-middle” attacks that underminethese additional layers of security. For example, a nefarious individualcan make it appear that communications between an online service and adevice in their possession are instead with a verification deviceassociated with a user account of the online service. It would thereforebe desirable to be able to verify subscriber information used to gainaccess to an online service.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a representative environment in which asubscriber-information authentication system may operate.

FIG. 2 is a block diagram illustrating a subscriber-informationauthentication system.

FIGS. 3 and 4 are flow diagrams illustrating processes implemented bythe subscriber-information authentication system for registeringinformation describing a subscriber or device with an account.

FIGS. 5 and 6 are flow diagrams illustrating processes implemented bythe subscriber-information authentication system for verifying a deviceused in part to access an account based on information registered withthe account,

DETAILED DESCRIPTION

A system and method to authenticate a verification device used to gainaccess to a user account is described herein. The subscriber-informationauthentication system uses information provided by a user, informationderived from a device being used by the user, information obtained froma communication network to which the user is subscribed, or acombination thereof, to authenticate that the device being used by theuser is a trusted verification device associated with the user account.

As described herein, by using certain subscriber information provided bya user to obtain from a communication network a hardware identifierassociated with a verification device, and comparing thenetwork-obtained hardware identifier to a comparable identifier derivedfrom the device being used by the user, the system can verify theveracity of the provided subscriber information. Once the authenticatedassociation between the user and the subscriber information has beenformed, the system can utilize the authenticated subscriber informationto facilitate subsequent accesses to the user account For example, insome embodiments the system may verify, without user interaction, that arequest to access an online service is made from a verification deviceassociated with the authenticated subscriber information for the useraccount. As a further example, in some embodiments the system verifiesthat messages received from a device during a code exchange are from thepurported verification device. It will be appreciated that theauthenticated subscriber information may be used to verify that a devicebeing used is the purported verification device in the context of otherdevice-based verification schemes.

In some embodiments, the subscriber information used by the system tofacilitate authentication is a subscriber identifier that identifies auser. The subscriber identifier may be a telephone number or a MobileStation International Subscriber Directory Number (MSISDN) of averification device associated with the user. The subscriber informationis associated with a user's mobile telecommunication subscription. Insome embodiments, the hardware identifier associated with a verificationdevice is an International Mobile Equipment Identity (IMEI) or anInternational Mobile Subscriber Identity (IMSI) in use or associatedwith the verification device. Although in some instances an IMSI isstored in a Subscriber Identity Module (SIM) card, and not the deviceitself, and therefore can be moved between devices, for purposes of thepresent disclosure an IMSI found in a SIM card may be treated as ahardware identifier, as the SIM card is installed in only one physicaldevice at a time. In some instances the IMSI is part of an Embedded SIM(eSIM) embedded within the verification device. It will be appreciatedthat other identifiers associated with a specific subscriber (andcorresponding telecommunication network subscription) or mobile devicemay be used.

In various embodiments, the system may use a combination of subscriberinformation and verification device information to form an authenticatedassociation between a user account and the subscriber information, suchas during an account registration process or during an account updateprocess. For example, during an account creation or update process thesystem may have the user provide, from the device the user intends to“register” as their verification device (e.g., their mobile telephone),the telephone number of that device. The system may also, using acapability provided by the device (e.g., using an API provided by thedevice operating system), obtain the IMSI of the device. Thedevice-obtained IMSI may be stored on the SIM card installed in thedevice or stored in a separate storage area of the device (e.g., aneSIM). Using the user-provided telephone number, the system queries acommunication network (e.g., the telecommunication network to which theuser subscribes) to derive the IMSI that the communication network hasassociated with the queried telephone number. If the device-obtained andthe network-derived IMSIs match, the system regards the user-providedtelephone number as being authenticated (i.e., the user provided thetrue telephone number from the device) and associates the telephonenumber with the created user account. As described herein, the systemuses the authenticated telephone number to facilitate subsequent accountaccesses.

In some embodiments, the system can identify the authenticated phonenumber of the intended verification device without user interactionduring an account creation or update process. For example, the systemcan obtain an IMSI from the user's device and use it to acquire acorresponding network-provided identifier (e.g., the MSISDN) from atelecommunication network. The system can then associate thenetwork-provided identifier with the user's account.

Furthermore, subsequent to association of the network-providedidentifier with the user's account, the system can utilize theauthenticated subscriber information to facilitate or enhancedevice-based verification performed prior to granting a user permissionto access an account. When a user uses a device to attempt to access anaccount of an online service, the system obtains the IMSI from thedevice used. The system also identifies the authenticated subscriberinformation, such as a telephone number, previously associated with theaccount for which access is sought. In some embodiments, the system usesthe device-obtained IMSI to query the telecommunication network anddetermine the telephone number associated with the IMSI; if thetelephone number determined based on the network query matches thetelephone number previously associated with the account, the device usedin connection with the access attempt is authenticated. In someembodiments, the system uses the previously associated telephone numberto query the telecommunication network and determine the IMSI associatedwith the authenticated telephone number; if the IMSI, determined basedon the network query, matches the IMSI obtained from the device, thedevice used in connection with the access attempt is authenticated. Insome embodiments, authenticating the device, based on a device-obtainedIMSI and a previously associated authenticated telephone number,constitutes the entirety of a device-based verification used toauthenticate a user attempting to access a user account. In someembodiments, authenticating the device as described is used incombination with other approaches for device-based verification (e.g.,code exchange or other forms of mufti-factor authentication that utilizea verification device). An advantage of some of the embodimentsdescribed is that security associated with accessing an account isenhanced (since a device must be authenticated to complete device-basedverification) without requiring further user interaction, therebyavoiding user interruption, reducing the likelihood of errors caused byuser typos in the entry of authentication passwords or codes, etc.

In some embodiments, the use of authenticated subscriber informationenables the verification of a device during account access, even if theuser has changed devices since the account was created. For example, ifa user obtains a new device but keeps their telephone number, the IMSIobtained from the new device will match the IMSI determined from anetwork query of the retained telephone number; therefore, as describedabove, the device will still be authenticated regardless of the user'schange in device. It will be appreciated that the system provides suchdevice-agnostic verification even if the user also obtains a new SIMcard with a different IMSI.

In some embodiments, the system obtains information associated with theuser's device (e.g., a network-derived IMSI, a network-derived telephonenumber, a network-derived MSISDN, or other form of identifier) from atelecommunication network by querying the telecommunication networkusing Signaling System No. 7 (“SS7”) protocols. The system may obtainthe device information by querying the network for routing informationassociated with a subscriber, for status information associated with asubscriber, for location information associated with a subscriber, etc.For example, the system may use one of the Mobile Application Part(“MAP”) protocol requests SendRoutingInformation (“SRI”), SRI-SM,SEND-IMSI, or “Restore Data” in order to obtain information associatedwith the user's device.

Various implementations of the system will now be described. Thefollowing description provides specific details for a thoroughunderstanding and an enabling description of these implementations. Oneskilled in the art will understand, however, that the system may bepracticed without many of these details or with alternative approaches.Additionally, some well-known structures or functions may not be shownor described in detail so as to avoid unnecessarily obscuring therelevant description of the various implementations. The terminologyused in the description presented below is intended to be interpreted inits broadest reasonable manner, even though it is being used inconjunction with a detailed description of certain specificimplementations of the system.

Suitable Environments

FIG. 1 and the following discussion provide a brief, general descriptionof a suitable environment in which a subscriber-informationauthentication system may be implemented. Although not required, aspectsof the system are described in the general context ofcomputer-executable instructions, such as routines executed by ageneral-purpose computer, a server, or other computing system. Thesystem can also be embodied in a special purpose computer or dataprocessor that is specifically programmed, configured, or constructed toperform one or more of the computer-executable instructions explained indetail herein. Indeed, the terms “computer” and “computing device,” asused generally herein, refer to devices that have a processor andnon-transitory memory, like any of the above devices, as well as anydata processor or any device capable of communicating with a network.Data processors include programmable general-purpose or special-purposemicroprocessors, programmable controllers, application-specificintegrated circuits (ASICs), programming logic devices (PLDs), or thelike, or a combination of such devices. Computer-executable instructionsmay be stored in memory, such as random access memory (RAM),read-onlymemory (ROM), flash memory, or the like, or a combination of suchcomponents. Computer-executable instructions may also be stored in oneor more storage devices, such as magnetic or optical-based disks, flashmemory devices, or any other type of non-volatile storage medium ornon-transitory medium for data. Computer-executable instructions mayinclude one or more program modules, which include routines, programs,objects, components, data structures, and so on that perform particulartasks or implement particular abstract data types.

Aspects of the system can also be practiced in distributed computingenvironments, where tasks or modules are performed by remote processingdevices, which are linked through a communications network, such as aLocal Area Network (“LAN”), Wide Area Network (“WAN”), or the Internet.In a distributed computing environment, program modules or subroutinesmay be located in both local and remote memory storage devices. Aspectsof the system described herein may be stored or distributed on tangible,non-transitory computer-readable media, including magnetic and opticallyreadable and removable computer discs, stored in firmware in chips(e.g., EEPROM chips). Alternatively, aspects of the system may bedistributed electronically over the Internet or over other networks(including wireless networks). Those skilled in the relevant art willrecognize that portions of the system may reside on a server computer,while corresponding portions may reside on a client computer.

FIG. 1 illustrates an example environment 100 in which asubscriber-information authentication system operates. The environment100 may include one or more end-user devices 102, which may be used by auser to access an authentication server 104 and one or more third-partyserver computers 106. Aspects of the subscriber-informationauthentication system may be practiced by the end-user devices 102, theauthentication server 104, and the third-party server computers 106.

The subscriber-information authentication system assists with theidentification and authentication of a user who is utilizing an end-userdevice 102 to access websites, applications, or other network-accessibleservices provided by the third-party server computers 106. For example,a user may attempt to access a network-accessible service with anend-user device 102 used as a “login device,” and the system mayauthenticate the user request based on, in part, verification of anend-user device 102 used as a “verification device.” The login deviceand verification device may be the same or different end-user device102. For example, in some embodiments the user uses a laptop computer asa login device and a mobile communication device (e.g., a smartphone) asa verification device. In some embodiments the user uses the same mobilecommunication device as the login device and the verification device.

As will be described in more detail herein, as part of an authenticationprocess, the system verifies that an end-user device 102 being used aspart of a verification process (i.e., the “verification device”) isproperly associated with a user account. To do so, the system obtains ahardware identifier 112 from the end-user device 102. For example, thehardware identifier 112 can be the IMSI 116 of the end-user device 102,which may be stored on the end-user device or on a SIM card 118installed in the end-user device 102. The hardware identifier 112 canalso be the IMEI of the end-user device 102. The end-user device 102 mayprovide the hardware identifier 112 in response to a command or requestreceived from the authentication server 104 or an application running onthe end-user device. The end-user device 102 may also provide, to theauthentication server 104, subscriber information 120 (e.g., a telephonenumber) provided by the user. The user may provide the subscriberinformation 120 using an interface to the end-user device 102 such as atouchscreen, a keyboard, etc. The system additionally obtains one ormore identifiers 114, used by a telecommunication network 110 to assistin identifying the end-user device 102, from the telecommunicationnetwork based on the subscriber information 120 or the hardwareidentifier 112. For example, the network identifiers 114 may be anetwork-derived IMSI 122 or a network-derived telephone number or MSISDN124. The network identifiers 114 may be determined based on, forexample, querying the Home Location Register (HLR) of thetelecommunication network 110. In some embodiments, network identifiers114 are derived based on information (e.g., subscriber information 120and IMSI 116) previously obtained by the system (e.g., during a priorregistration process) and maintained by the system. As described herein,by comparing network identifiers 114 to comparable identifiers (e.g.,subscriber information 120 or IMSI 116) either provided by the end-userdevice 102 or maintained by the system in association with a useraccount, the system is able to verify that the end-user device 102 usedin connection with user account access is an authorized device for theaccount. Verifying that account access is truthfully coming from adevice authorized to access the user account can be used as a layer of amufti-layered authentication scheme, used in conjunction, for example,with username and password checks, one-time or limited-time passcode orcode exchange, or other techniques that provide Mufti-FactorAuthentication (MFA).

The end-user devices 102, authentication server 104, and third-partyserver computers 106 communicate with each other through one or morepublic or private, wired or wireless communication networks 108,including, for example, the Internet and telecommunication network 110.The end-user devices 102 communicate wirelessly with a base station oraccess point using a wireless mobile telephone standard, such as theGlobal System for Mobile Communications (GSM), Long Term Evolution(LTE), IEEE 802.11 (Wi-Fi), or another wireless standard, and the basestation or access point communicates with authentication server 104 andthird-party server computers 106. The end-user devices 102 additionallycommunicate wirelessly with the communication network 108, for example,nearby cell towers or base stations using wireless mobile telephonestandards, such as Global System for Mobile Communications (GSM), CDMA(Code Division Multiple Access), General Packet Radio Service (CPRS),and the like. The telecommunication network 110 may support and beoperated using SS7 protocols and procedures. The communication network108 and telecommunication network 110 may be interconnected such that,for example, an end-user device 102 connected to the telecommunicationnetwork 110 can communicate via the communication network 108 withauthentication server 104, third-party server computers 106, and otherdevices connected to the network. The end-user device 102 utilizesapplications or other software, which operate through the use ofcomputer executable instructions. Some such applications may be directedtoward the user authentication process (e.g., receiving a one-time codefrom the system and providing it to a user). As will be described inmore detail herein, the authentication system residing at least in parton the authentication server 104 may also utilize software whichoperates through the use of computer-executable instructions as part ofthe authentication process.

Suitable System

FIG. 2 is a block diagram illustrating a subscriber-informationauthentication system 200. Aspects of the system may be practiced oncomputing devices operated by end-users, computing devices operated byauthentication service providers, computing devices operated by thirdparties (e.g., entities or services utilizing or requiring theauthentication service), or a combination thereof.

An interface module 202 generates graphical user interfaces (GUIs) toallow users to access the subscriber-information authentication system200. For example, the interface module 202 generates a GUI that displaysprompts or requests to a user in order to obtain subscriber informationfrom the user. The interface module 202 also provides applicationprogramming interfaces (APIs) to enable communication and interfacingwith the system 200. APIs may be utilized by other applications, webportals, or distributed system components to use the system. Forexample, APIs provided by the interface module 202 may be used tointegrate with a third-party service provider that implements orfacilitates authentication services or services available to the userafter authentication, including the data or the functions accessiblesubsequent to authentication of a user. The user of an end-user devicemay use an API to interface with system servers and access data orfunctionalities from the devices operated by third parties. The API mayutilize, for example, Representational State Transfer (REST)architecture and Simple Object Access Protocols (SOAPS).

A device-side module 204 interacts with end-user devices for determiningcertain device-obtained information. The device-side module 204 can, forexample, interact directly with the end-user device via calls orrequests to the device. The device-side module 204 can include one ormore network adapters or communication circuitry, one or moreprocessors, associated configurations or APIs, or a combination thereoffor communicating with end-user devices. The device-side module 204 can,for example, obtain from an end-user device the device's IMSI or certaincorresponding subscriber information, such as the telephone number orMSISDN associated with the device. The device-side module 204 can alsoobtain said information from a user through the interface module 202.The device-side module 204 can also provide said information to otherdevices, such as authentication servers or third-party computing devicesused by the system.

A network-side module 206 interacts with a telecommunication network todetermine information, such as device or subscriber identifiers, fromthe telecommunication network. The network-side module 206 cancommunicate with and retrieve information from the telecommunicationnetwork through various SS7 protocols. For example, the network-sidemodule 206 can use SS7 commands to query components of thetelecommunication network, such as a HLR, to obtain the IMSI ortelephone number associated with an end-user device. The network-sidemodule 206 can include one or more network adapters or communicationcircuitry, one or more processors, associated configurations or API, ora combination thereof.

An authentication logic module 210 processes information received viathe interface module 202, the device-side module 204, or thenetwork-side module 206 in order to authenticate the user's device asdescribed herein. The authentication logic module 210 coordinatesappropriate calls and sequencing of requests by each of the othermodules as necessary to either verify a user's device or not verify theuser's device for failure to pass one or more of the confirmatory checksset forth herein.

The interface module 202, the device-side module 204, the network-sidemodule 206, and the authentication logic module 210 can access userinformation or device information in storage areas 208. The accesseddata may be stored in any readily accessible format, including datamaintained by a database management system (e.g., MYSQL, Microsoft SQLServer, Oracle, MongoDB), or in any relational, non-relational, object,or objection-relational database.

Flows for a Subscriber-Information Authentication System

FIGS. 3 and 4 are flow diagrams illustrating example processes 300 and400, respectively, implemented by a subscriber-informationauthentication system, for obtaining or verifying certain subscriberinformation (such as a telephone number) associated with an end-userdevice. As described herein, FIG. 3 illustrates generally a process inwhich subscriber information provided by a user is compared againstinformation derived from a telecommunication network, thereby verifyingthe user-provided information. As described herein, FIG. 4 illustratesgenerally a process in which subscriber information is derived from atelecommunication network based on one or more identifiers obtaineddirectly from an end-user device, and is therefore considered verified.By verifying certain subscriber information, such as a telephone number,that information may be “registered” or associated with a user account,and may be used to facilitate subsequent authentication during attemptsto access the user account. The processes 300 and 400 can occur, forexample, when the user account is first created or during a later stageof account registration.

Referring to FIG. 3 , the process 300 begins at block 305, where thesystem receives a request to register certain subscriber informationwith a user account. The request may be received, for example, as partof an account creation process or after the account has already beencreated.

At a block 310, the system obtains subscriber information from a user.For example, as part of a registration step, the user may be prompted bythe system to enter a phone number associated with a verification devicethat the user intends to register. The prompt may be displayed on theverification device or some other computing device being used by theuser. The user may provide the requested subscriber information to thesystem via the verification device or another computing device.

At a block 315, the system queries a telecommunication network for thenetwork's information associated with the user-provided subscriberinformation. The system can, for example, query the telecommunicationnetwork to which the verification device is a subscriber. The system canalso query other telecommunication networks of which the verificationdevice is not a subscriber. For example, certain telecommunicationnetworks share subscriber and device information with each other, whichthe system can query. The system can perform the query using an SRIrequest, an SRI-SM request, or other request for routing or statusinformation from the network. It will be appreciated that other MAPrequests or SS7 protocols may be used to obtain identifier informationfrom the network.

At a block 320, the system receives information from thetelecommunication network associated with the queried subscriberinformation. The received network information indicates the location ofthe corresponding subscriber, availability, and other routinginformation. The network information additionally includes an identifiercorresponding to the device currently associated with the providedsubscriber information, which may be used by the telecommunicationnetwork to facilitate management of and communication with the device.One example of a hardware identifier used by the network to facilitatemanagement of a device is the HSI of the device, though other identifiesassociated with a device can be used. If available, the receivedinformation could therefore include the IMSI associated with the devicepresently corresponding to a queried telephone number. Thenetwork-derived IMSI may be determined, for example, based on thetelecommunication network performing a query of its HLR based onprovided subscriber information.

At a block 325, the system obtains a hardware identifier from theverification device that the user intends to register. For example, thesystem may obtain the IMSI from the device. In order to provide its IMSIto the system, the device obtains its IMSI in response to an applicationor operating system request. For example, a device running on theAndroid operating system may return its IMSI in response to agetSubscriberId( ) function call. In response, the device provides theIMSI for the SIM card installed in the device. It will be appreciatedhowever that other techniques exist, both on Android and other operatingsystems used by devices, to obtain the IMSI of the device as well asother identifiers that uniquely identify the device or installed SIMcard.

At a decision block 330, the system determines whether a hardwareidentifier obtained from the device and a hardware identifier receivedfrom the telecommunication network match. For example, the system maycompare the device IMSIs obtained as described in connection with blocks320 and 325. If the two hardware identifiers match, processing continuesto a block 340. If the two hardware identifiers do not match, processingcontinues to block 335.

If at decision block 330 it was determined that the two hardwareidentifiers do not match, then at block 335 the system identifies thatthe subscriber information provided by the user has not beenauthenticated. That is, according to the telecommunication network, thedevice corresponding to the provided user information is different fromthe device the user intends to register as a verification device for auser account. When that occurs, the subscriber information or hardwareidentifier is not registered with the user account. In some embodimentsthe process may end. In some embodiments the process may requestsubscriber information again from the user (in case the user incorrectlyentered the information), for example by returning to block 310. Theprocess then terminates.

If at decision block 330 it was determined that the two hardwareidentifiers match, then at block 340 the provided subscriber informationis authenticated. That is, according to the telecommunication network,the device corresponding to the provided user information is the same asthe device the user intends to register as a verification device for auser account. In other words, the provided subscriber information can betreated as authenticated for association with a user account.

At a block 345, authenticated information is stored in association witha user account. For example, a user may be creating a new account with athird-party service, and the authenticated information may have beenidentified and verified in connection with an account registration orcreation process. The system stores the authenticated subscriberinformation, such as a telephone number or MSISDN, or authenticatedhardware identifier, such as an IMSI or !MEI, or a combination thereof,in association with the user's account. As described herein, the storedauthenticated information can be used to facilitate subsequentverification of a device in connection with a later account access. Theprocess then terminates.

Referring to FIG. 4 , process 400 illustrates an additional exampleprocess that can be executed by the subscriber-informationauthentication system to obtain verified subscriber informationassociated with an end-user device. The process begins at a block 405,where the system receives a request to register certain subscriberinformation with a user account. The request may be received, forexample, as part of an account creation process or after the account hasalready been created.

At a block 410, the system obtains a hardware identifier from averification device that the user intends to register for the account.For example, the system may obtain the IMSI from the device. The devicemay obtain its IMSI, to be provided to the system, in response to anapplication or operating system request. For example, a device runningon the Android operating system may return its IMSI in response to agetSubscriberId( ) function cell In response, the device provides theIMSI for the SIM card installed in the device. It will be appreciatedhowever that other techniques exist, both on Android and other operatingsystems used by devices, to obtain the IMSI of the device as well asother identifiers that uniquely identify the device or installed SIMcard.

At a block 415, the system retrieves subscriber information from atelecommunication network based on the obtained hardware identifier. Forexample, the system can query the telecommunication network to which thedevice is subscribed, or another telecommunication network that sharedinformation with the subscriber network, to retrieve subscriberinformation corresponding to the obtained IMSI using the “Restore Data”command. Retrieved subscriber information may include the telephonenumber or MSISDN corresponding to the queried IMSI. It will beappreciated, however, that other SS7 commands or requests may be used toobtain information from a telecommunication network regarding thesubscriber associated with a particular hardware identifier.

At a block 420, authenticated information is stored in association witha user account. For example, a user may be creating a new account with athird-party service or updating an existing account, and theauthenticated information may have been identified and verified inconnection with an account creation or update process. The system storesthe authenticated subscriber information, such as a telephone number orMSISDN, in association with the user's account. As a further example,the system can store an authenticated hardware identifier, such as anIMSI or IMEI of the requesting device, in association with the user'saccount. As described herein, the stored authenticated information canbe used to facilitate subsequent verification of a device in connectionwith a later account access. The process then terminates.

FIGS. 5 and 6 are flow diagrams illustrating example processes 500 and600, respectively, implemented by a subscriber-informationauthentication system, for verifying that device information isconsistent with previously-identified device information. The processes500 and 600 may be used, for example, to verify that a device being usedin connection with accessing a previously-registered account ispermitted. As described herein, both processes 500 and 600 utilizecertain information already associated with the account (from, forexample, a prior registration process) as well as certain informationobtained from the device at the time of attempted account access; theprocesses differ, for example, in how the information is used to verifythe device.

Referring to FIG. 5 , process 500 begins at a block 505, where thesystem receives an individual request to access an online service. Therequest may include information identifying a user account previouslyregistered with the service (e.g., a username), which is associated witha user profile maintained by the system.

At a block 510, the system obtains a hardware identifier from a devicethat the user intends to use as a verification device for accessing theaccount. The verification device may be the device from which the userattempts to access the account. Alternatively, the verification devicemay be different from the device used to access the account, but may beutilized for further device-based verification prior to account access.At block 510, the system may, for example, obtain the IMSI from thedevice. The device may obtain its IMSI in response to an application oroperating system request. For example, a device running on the Androidoperating system may return its IMSI in response to a getSubscriberId( )function call. In response, the device provides the IMSI for the SIMcard installed in the device. It will be appreciated however that othertechniques exist, both on Android and other operating systems used bydevices, to obtain the IMSI of the device as well as other identifiersthat uniquely identify the device or installed SIM card.

At a block 515, the system retrieves subscriber information from atelecommunication network, such as the telecommunication network towhich the device is subscribed or a telecommunication network thatshares data with the subscriber network, based on the obtained hardwareidentifier. For example, the system can query the telecommunicationnetwork to retrieve subscriber information corresponding to the obtainedIMSI using the “Restore Data” command. Retrieved subscriber informationmay include the telephone number or MSISDN corresponding to the queriedIMSI. It will be appreciated, however, that other SS7 commands orrequests may be used to obtain information from a telecommunicationnetwork regarding the subscriber associated with a particular hardwareidentifier.

At a block 520, the system retrieves subscriber information from theuser profile maintained by the system. In connection with the userprofile, the system maintains known subscriber information for the useraccount, such as may have been generated during a prior registration orcreation process (such as those illustrated in FIGS. 3 and 4 ). Themaintained subscriber information may include, for example, a telephonenumber or MSISDN that has been verified as being associated with theaccount.

At a decision block 525, the system determines whether subscriberinformation retrieved from the user profile and subscriber informationretrieved from the network (based on the hardware identifier obtainedfrom the device) match. For example, the system may compare the storedand received telephone numbers or the stored and received MSISDNs. Ifthe subscriber information matches, processing continues to a block 530.If the subscriber information does not match, processing continues to ablock 535.

If at the decision block 525 it was determined that theprofile-retrieved and network-retrieved subscriber information matches,then at block 530 the system identifies that the verification deviceused in connection with account access has been authenticated. That is,the device is provisioned, according to the telecommunication network,to the subscriber information (e.g., telephone number) that waspreviously registered for accessing the user account. Accordingly, thedevice is authenticated, and access to the user account may proceed. Anauthorization indication that the device has been authenticated may betransmitted by the system to, for example, the third-party servicecorresponding to the account the user wishes to access. In someembodiments the device authentication is used in combination withtraditional account verification steps (e.g., a username and passwordcheck), as well as device-based verification steps (e.g., code exchangeusing the device), in order to gain access to the account or servicesassociated with the account; the exemplary additional verification stepsmay be conducted prior, after, or in parallel with the illustratedprocess 500. The process then terminates.

If at the decision block 525 it was determined that theprofile-retrieved and network-retrieved subscriber information does notmatch, then at block 535 the system designates the device being used inconnection with attempted account access to not be authenticated. Thatis, the device is not provisioned to the subscriber information (e.g.,telephone number) previously registered for accessing the user account.An indication that the device has not been authenticated may betransmitted by the system to, for example, the third-party servicecorresponding to the account the user wishes to access. In someembodiments, the attempt to access the user account may be denied inresponse to the indication. In some embodiments, the system, such as athird-party computing device or the authentication server, could requireadditional or alternative verification checks prior to granting the useraccess. The process then terminates.

Referring to FIG. 6 , the process 600 illustrates an additional exampleprocess implemented by a subscriber-information authentication systemfor verifying a device used in connection with accessing a user account.The process begins at a block 605, where the system receives anindividual request to access an online service. The request may includeinformation identifying a user account previously registered with theservice (e.g., a username), which is associated with a user profilemaintained by the system.

At a block 610, the system retrieves subscriber information from theuser profile maintained by the system. In connection with the userprofile, the system maintains known subscriber information for the useraccount, such as may have been generated during a prior registration orcreation process (such as those illustrated in FIGS. 3 and 4 ). Themaintained subscriber information may include, for example, a telephonenumber or MSISDN that has been verified as being associated with theaccount.

At a block 615, the system queries a telecommunication network for thenetwork's information associated with subscriber information maintainedin the user profile. The system may query the telecommunication networkcorresponding to the service subscription associated with the subscriberinformation, or another telecommunication network that shares data withthe subscriber network. For example, the system may query the networkfor information associated with a telephone number by sending an SRIrequest, an SRI-SM request, or other request for routing or statusinformation from the network. It will be appreciated that other MAPrequests or SS7 protocols may be used to obtain identifier informationfrom the network.

At a block 620, the system receives information from thetelecommunication network associated with the queried subscriberinformation. The received network information indicates the location ofthe corresponding subscriber, availability, and other routinginformation. The network information additionally includes an identifiercorresponding to the device currently associated with the providedsubscriber information, which may be used by the telecommunicationnetwork to facilitate management of and communication with the device.For example, the received information may include the IMSI associatedwith the device presently corresponding to a queried telephone number.The network-derived IMSI may be determined, for example, based on thetelecommunication network performing a query of its HLR based onprovided subscriber information.

At a block 625, the system obtains a hardware identifier from theverification device used to verify the user's request to access the useraccount. For example, the system may obtain the IMSI or IMEI from thedevice. The device may obtain its IMSI in response to an application oroperating system request. For example, a device running on the Androidoperating system may return its IMSI in response to a getSubscriberId( )function call. In response, the device provides the IMSI for the SIMcard installed in the device. It will be appreciated however that othertechniques exist, both on Android and other operating systems used bydevices, to obtain the IMSI of the device as well as other identifiersthat uniquely identify the device or installed SIM card.

At a decision block 630, the system determines whether a hardwareidentifier obtained from the device and a hardware identifier receivedfrom the telecommunication network match. For example, the system maycompare the device IMSIs obtained as described in connection with blocks620 and 625. If the two hardware identifiers match, processing continuesto a block 635. If the two hardware identifiers do not match, processingcontinues to block 640.

If at decision block 630 it was determined that the device-retrieved andnetwork-retrieved hardware identifier matches, then at block 635 thesystem identifies that the verification device used in connection withaccount access has been authenticated. That is, the telecommunicationnetwork's notion of what device is provisioned to the subscriberinformation (e.g., the subscriber's telephone number) that waspreviously registered is the same as the device being used to requestaccess. Accordingly, the device is authenticated, and access to the useraccount or to services associated with the user account may proceed. Anauthorization indication that the device has been authenticated may betransmitted by the system to, for example, the third-party service theuser wishes to access corresponding to the user account. In someembodiments the device authentication is used in combination withtraditional account verification steps (e.g., a username and passwordcheck), as well as device-based verification steps (e.g., code exchangeusing the device), in order to gain access to the account; the exemplaryadditional verification steps may be conducted prior, after, or inparallel with the illustrated process 600. The process then terminates.

If at the decision block 630 it was determined that the device-retrievedand network-retrieved hardware identifiers do not match, then at block640 the system designates the device being used in connection withattempted account access to not be authenticated. That is, the devicebeing used to facilitate access to the account is not the one thetelecommunication network believes is provisioned to the subscriberinformation (e.g., telephone number) previously registered for accessingthe user account. An indication that the device has not beenauthenticated may be transmitted to, for example, the third-partyservice corresponding to the account the user wishes to access. In someembodiments the attempt to access the user account may be denied inresponse to the indication. In some embodiments the system, such as athird-party computing device or the authentication server, could requireadditional or alternative verification checks prior to granting the useraccess. The process then terminates.

It will be appreciated that example authentication processes 500 and 600may enable authentication of a verification device even when theverification device changes subsequent to account creation. If afterregistering an account a user obtains a new device or SIM card, it isunderstood that certain hardware identifiers will change. For example, anew SIM card may be provisioned with a new IMSI, while a new device willbe associated with a new IMEI. If the user retains their telephonenumber, the network information will in time update to reflect the factthat the retained telephone number has been provisioned to a new deviceor SIM, with corresponding new hardware identifier. Therefore, when theuser later attempts to access an account with the new device, thenetwork-retrieved hardware identifier (e.g., IMSI or IMEI) will matchthat retrieved from the new device. Accordingly, the new device willcontinue to be authenticated per the illustrated processes.

The above Detailed Description of examples of the disclosed technologyis not intended to be exhaustive or to limit the disclosed technology tothe precise form disclosed above. While specific examples for thedisclosed technology are described above for illustrative purposes,various equivalent modifications are possible within the scope of thedisclosed technology, as those skilled in the relevant art willrecognize. For example, while processes or blocks are presented in agiven order, alternative implementations may perform routines havingsteps, or employ systems having blocks, in a different order, and someprocesses or blocks may be deleted, moved, added, subdivided, combined,and/or modified to provide alternative or sub-combinations. Each ofthese processes or blocks may be implemented in a variety of differentways. Also, while processes or blocks are at times shown as beingperformed in series, these processes or blocks may instead be performedor implemented in parallel, or may be performed at different times.Further, any specific numbers noted herein are only examples;alternative implementations may employ differing values or ranges.

These and other changes can be made to the disclosed technology in lightof the above Detailed Description. While the Detailed Descriptiondescribes certain examples of the disclosed technology as well as thebest mode contemplated, the disclosed technology can be practiced inmany ways, no matter how detailed the above description appears in text.Details of the system may vary considerably in its specificimplementation, while still being encompassed by the technologydisclosed herein. As noted above, particular terminology used whendescribing certain features or aspects of the disclosed technologyshould not be taken to imply that the terminology is being redefinedherein to be restricted to any specific characteristics, features, oraspects of the disclosed technology with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the disclosed technology to the specificexamples disclosed in the specification, unless the above DetailedDescription section explicitly defines such terms.

I/we claim:
 1. A computer-implemented method of performing a deviceverification check in response to a user request to access anetwork-accessible service, the method comprising: receiving a requestto access a network-accessible service by a user, the user associatedwith a user profile of the network-accessible service, wherein the userprofile of the network-accessible service comprises a subscriberidentifier for a mobile telecommunication subscription, and wherein themobile telecommunication subscription is distinct from the network-accessible service; obtaining, from the user profile, the subscriberidentifier; obtaining, from a mobile communication device associatedwith the user, a hardware identifier; transmitting, to atelecommunication network, a query for network-derived informationassociated with one of the subscriber identifier or the hardwareidentifier; receiving, from the telecommunication network, a queryresponse that comprises a network-derived identifier associated by thetelecommunication network with the one of the subscriber identifier orthe hardware identifier; comparing the network-derived identifier withthe other of the subscriber identifier or the hardware identifier;performing a verification check based on the user request or the userprofile; and generating, based on the comparison and the verificationcheck, an authorization indication in response to the user request,based on which the network-accessible service can approve or deny theuser request.
 2. The method of claim 1, the method further comprisingreceiving a user identifier and a password, and wherein the verificationcheck comprises comparing the user identifier and the password with auser identifier and a password associated with the user profile.
 3. Themethod of claim 1, the method further comprising receiving a one-timepasscode, and wherein the verification check comprises comparing theone-time passcode to a passcode generated in response to the userrequest.
 4. The method of claim 1, wherein the subscriber identifier wasassociated with the user profile during a registration process.
 5. Themethod of claim 1, wherein the subscriber identifier was associated withthe user profile by: receiving a request to associate user subscriberinformation with the user profile; obtaining, from a mobilecommunication device associated with the request to associate usersubscriber information was received, a second hardware identifier;determining, based on querying the telecommunication network, asubscriber identifier associated with the second hardware identifier;and associating the subscriber identifier with the user profile.
 6. Themethod of claim 1, wherein the subscriber identifier was associated withthe user profile by: receiving a request to associate user subscriberinformation with the user profile, wherein the request comprises auser-provided subscriber identifier; obtaining, from a mobilecommunication device associated with the request to associate usersubscriber information was received, a device-obtained hardwareidentifier; determining, based on querying the telecommunicationnetwork, a network-derived hardware identifier based on theuser-provided subscriber identifier; and associating, based on acomparison of the device-obtained hardware identifier and thenetwork-derived hardware identifier, the user-provided subscriberidentifier with the user profile.
 7. The method of claim 1, wherein thesubscriber identifier is a telephone number associated with the mobiletelecommunication subscription.
 8. The method of claim 1, wherein thehardware identifier is associated with the mobile communication device.9. The method of claim 1, wherein the hardware identifier is aninternational mobile subscriber identity (IMSI) or an internationalmobile equipment identity (IMEI).
 10. The method of claim 1, wherein thequery is for network-derived information associated with the subscriberidentifier, and wherein the query is a SendRoutingInformation (SRI) oran SRI-SM request.
 11. A computer-implemented method for performing adevice verification check in response to a user request to access anetwork-accessible service, the method comprising: receiving a requestby a user to register with a network-accessible service; obtaining, froma mobile communication device associated with the registration requestof the user, a first identifier; receiving, from a telecommunicationnetwork, a second identifier associated by the telecommunication networkwith the first identifier; generating a user profile, associated withthe user, for the network-accessible service, the user profilecomprising the second identifier; receiving a request to access thenetwork-accessible service by the user; obtaining, from a mobilecommunication associated with the request to access thenetwork-accessible service was received, a third identifier; receiving,from the telecommunication network, a fourth identifier associated bythe telecommunication network with the third identifier; comparing thesecond identifier and the fourth identifier; performing a verificationcheck based on the request to access the network-accessible service orthe user profile; and generating, based on the comparison and theverification check, an authorization indication in response to therequest to access the network-accessible service, based on which thenetwork-accessible service can approve or deny the request.
 12. Themethod of claim 11, wherein the request to access the network-accessibleservice comprises a user identifier and a password, and wherein theverification check comprises comparing the user identifier and thepassword to a user identifier and a password associated with the userprofile.
 13. The method of claim 11, the method further comprisingreceiving a one-time passcode, and wherein the verification checkcomprises comparing the one-time passcode to a passcode generated inresponse to the request to access the network-accessible service. 14.The method of claim 11, wherein the first identifier and the thirdidentifier are hardware identifiers associated with mobile communicationdevices.
 15. The method of claim 14, wherein the hardware identifiersare international mobile subscriber identities (IMSIs) or internationalmobile equipment identifies (IMEIs).
 16. The method of claim 11, whereinthe second identifier and the fourth identifier are subscriberidentifiers associated with a mobile telecommunication subscription. 17.The method of claim 11, wherein the first identifier and the thirdidentifier match.
 18. The method of claim 11, wherein the firstidentifier and the third identifier are different.
 19. Acomputer-implemented method of generating an association betweensubscriber information and a user account, the method comprising:receiving a request to associate authentication information with a useraccount for a network-accessible service, the request including a useridentifier and password; obtaining, from a mobile communication deviceassociated with the request to associate authentication information wasreceived, a hardware identifier; transmitting, to a telecommunicationnetwork, a query for network-derived information associated with thehardware identifier; receiving, from the telecommunication network, aquery response that comprises a subscriber identifier for a mobiletelecommunication subscription, wherein the mobile telecommunicationsubscription is distinct from the network-accessible service;determining whether the user identifier and the password match a useridentifier and a password associated with the user account; andassociating, based on the determination, the subscriber identifier withthe user account.
 20. The method of claim 19, the method furthercomprising associating the hardware identifier with the user account.